AWS ParallelCluster Manager のバージョン違いで複数環境を持つときに検討してもらいたいこと
既存の AWS ParallelCluster Manager をアップデートせずに新しいバージョンの AWS ParallelCluster Manager を新規デプロイする方法を紹介します。別な環境を構築するゆえの弊害も生まれましたのであわせてご確認ください。
検証環境
- AWS ParallelCluster Manger 3.2.0
- AWS ParallelCluster Manger 3.3.0
検証結果
- CloudFormation テンプレートはスタック名を変更してデプロイするだけ
- 複数環境を保持してもランニングコストはほぼ発生しない
- 新環境と別環境はログイン URL が異なる
- Cognito で管理しているログインユーザーの再登録が必要
- ログ参照用途の利用であれば旧バージョン環境は削除したい
複数環境のデプロイ方法
構築手順は一箇所変更するだけで通常デプロイ方法と違いはありません。
手順変更箇所
CloudFormation テンプレートを利用して自身の AWS アカウントにデプロイするときのスタック名をユニークな名前へ変更する点が異なります。
東京リージョンへデプロイする場合を例に具体的な箇所を説明します。以下のリンクをクリックすると東京リージョン用の CloudFormation のパラメーター入力画面になります。
デフォルトのスタック名（pcluster-maanger）が既存の AWS ParallelCluster Manager のスタック名と重複してしまうと新たにデプロイできません。
スタック名をユニークな名前へ変更します。わかりやすく AWS ParallelCluster のバージョン名をスタックに付与しました。
後はスタックを実行するだけです。
別環境が作られる弊害について
AWS ParallelCluster Manager の新バージョンを別環境として簡単にデプロイできました。ただ、別環境ゆえに弊害があります。
一番大きな弊害はログインユーザーの再登録が必要になります。AWS ParallelCluster Manager のログインユーザーは Cognito で管理されています。Cognito のユーザープールが別れてしまうためユーザー登録をやり直す必要があります。お一人様 AWS ParallelCluster Manager 環境でしたらさほど手間ではないです。
次に AWS ParallelCluster Manager へログイン先の URL が変わります。この URL は API Gateway の URL がそのまま使われています。複数人でログインする環境でしたら Route 53 のエイリアスを利用して管理するのも手かもしれません。
古いバージョンは必要なのか？
AWS ParallelCluster Manager の新バージョンの環境を作成後、古いバージョンの環境は必要なのでしょうか？
AWS ParallelCluster Manager からクラスターを作成するときは AWS ParallelCluster Manager のバージョン = クラスターのバージョンになります。クラスター作成環境として利用している場合は旧バージョン環境を残す価値はありますね。
ヘッドノードや、コンピュートノードのログ参照用途で AWS ParallelCluster Manager を利用する場合は下位互換性があるため、新バージョンの環境だけあれば困ることはありません。
AWS ParallelCluster Manager のログインに MFA 有効化する事前準備がやや手間なため、MFA を設定しない環境でしたら旧バージョンの環境を削除してしまい不正利用リスクをなくした方がよろしいかと思います。
おわりに
本当は AWS ParallelCluster Manager をアップデートしたかったのですがアップデート完了しても新バージョンにならないため、ワークアラウンドとして別環境を作成することができるのか検証してみました。結果、別環境を作成することは問題なく、かつ作ること自体は簡単でした。ただ、Cognito のユーザー再登録が痛いです。複数人でご利用いただいている環境ですとアップデートせざるおえないですね。
